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REMARKS 
Status Summary 

In this Amendment, no claims are cancelled, and claims 65-78 are added. 
Therefore, upon entry of this Amendment, claims 1-78 will be pending. 



Claim Rejections 35 U.S.C. § 102 

Claims 1, 6-8, 11-18, 22-26, 29, 35, 48, 49, 51-59, and 61-64 were rejected 
under 35 U.S.C. § 102(e) as anticipated by U.S. Patent No. 6,304,565 to 
Ramamurthy (hereinafter, " Ramamurthy "). This rejection is respectfully traversed. 

The present invention, for example as claimed in independent claims 1,11, 
22, 29, 35, 42, and 51 includes methods and systems for automatically updating 
presence information stored in a presence database or for obtaining information from 
such a database. The claims have been amended to clarify that presence 
information is information useable by a presence server for automatically indicating to 
other end users who are subscribed to a target end user in a presence database a 
communication medium for contacting the target end user using a text messaging 
protocol and indicating that the target end user is currently available to receive 
messages via the text messaging protocol. For example, as described on page 4 
beginning at line 14 of the present specification, the presence protocol may be used 
as follows: 

A typical example of how the presence protocol may be used is as 
follows. An entity A to an endpoint E may be subscribed through a 



-20- 



Serial No. 09/627,253 



presence server P to another entity B. When the status of B changes, 
P will notify E of the change in status of B. 



The present invention includes methods and systems for automatically updating such 
information in a presence database (independent claims 1, 22, 29, and 42) and 
obtaining such information from a presence database (independent claims 11, 35, 
and 51). 

Ramamurthy has absolutely nothing to do with the presence protocol, 

registering presence information in a presence database, or responding to presence 

queries. Ramamurthy is directed to methods for processing telephone calls when a 

called party's telephone line is busy because the called party is accessing the 

Internet using his or her telephone line. (See column 1 , lines 34-40 of Ramamurthy .) 

According to Ramamurthy , an incoming call to a called party whose telephone line is 

busy because the called party is using the telephone line to access the Internet can 

be processed in a number of ways: 

If the telephone line is active, IP-telephony-capable, currently active 
on an IP telephony call, and the called party subscribes to a call 
waiting on IP feature, then the incoming call can be forwarded as an 
IP telephony call to the called telephone line if the called party agrees 
to accept the incoming call and places his current call on hold. If the 
called party does not subscribe to a call waiting on IP feature but 
subscribes to a call forwarding on IP feature, the incoming call can be 
directed to an alternate destination on either the IP network or the 
PSTN, such as a voice mail or message service. If the called party is 
currently active on the IP network, has an IP telephony capability, but 
is not currently active on an IP telephony call, which is the common 
scenario when the called party is browsing, then the called party is 
alerted to the incoming telephone call via a message on his terminal. 
The called party can then elect to accept the incoming call and the call 
is completed through the ITN to the called party as an Internet 
telephony call regardless of whether or not the called party subscribes 
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to a call waiting on IP feature. If the called party is currently active on 
the IP network through an ISP, but does not have an IP telephony 
capability, then the PSTN can forward a message to the ISP which 
will push the message to the called party and inform him of the 
incoming call. (See column 2, lines 22-45 of Ramamurthv .) 



Thus, Ramamurthv discloses several methods for processing calls when the called 
party telephone line is being used for Internet activities. There is no mention of 
automatically generating presence registration messages or processing queries to a 
presence database as claimed. Thus, for this reason alone, the rejection of claims as 
anticipated by Ramamurthv should be withdrawn. 

Moreover, paragraph 3 of the Official Action indicates: 

Ramamurthv discloses. . . 

(a) receiving a signaling system 7 (SS7) message in response to a 
telephony related action performed by an end user (Figure 2, column 
4, lines 51-52); 

(b) determining based on the SS7 message, whether presence 
registration processing is required for the end user (column 4, lines 
52-57); 

(c) in response to determining that presence registration processing 
is required for the end user, automatically generating a presence 
registration message including presence information indicating to 
other end users for contacting the end user using a messaging 
protocol and indicating that the end user is available to receive 
message protocol messages via the communications medium (Figure 
3, column 5, lines 56-51); and 

(d) transmitting the presence registration message to the presence 
server over an IP network (Figure 1, column 3, lines 41-43). 



The portions of Ramamurthv cited by the Examiner fail to teach the invention as 
claimed. 
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With regard to step (a) of claim 1, Figure 2 and column 4, lines 51-52 of 
Ramamurthv cited in the Official Action regarding step (a) describe the action of the 
calling party dialing the called party's telephone number. In contrast, step (a) of claim 
1 has been amended to recite receiving a signaling system 7 message in response to 
a telephony related action performed by a target end user to which other end users 
are subscribed in a presence database. In other words, claim 1 relates to an action 
performed by the end user seeking to be contacted, rather than the calling party. 

Step (b) of claim 1 recites determining, based on the SS7 message, whether 
presence registration processing is required for the end user. Column 4, lines 52-57 
of Ramamurthv cited in the Official Action regarding step (b) of claim 1 states as 
follows: 

At step 202, the PSTN 104 receives the dialed number over the SS7 
signaling network. At step 203, the PSTN 104 accesses database 
112 through telephone server 111, which is commonly accessible 
from ITN 100 and PSTN 104, to determine, at step 204, if the 
telephone line identified by the dialed number is currently active on a 
packet-based data network. 

The cited portion of Ramamurthv states that a database is accessed to determine 
whether the called party's line is busy. There is no teaching or suggestion of 
determining whether presence registration processing is required. As indicated in 
claim 1 , presence information includes information usable by a presence server for 
automatically indicating to other end users who are subscribed to the end user in a 
presence database a communication medium for contacting the end user via a text 
messaging protocol. There is simply no such teaching in Ramamurthv . 
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Step (c) of claim 1 recites: 

in response to determining that presence registration processing is 
required for the end user, automatically generating a presence 
registration message including presence information usable by a 
presence server for automatically indicating to other end users who 
are subscribed to the end user in a presence database a 
communication medium for contacting the end user via a text 
messaging protocol and indicating that the end user is currently 
available to receive text messaging protocol messages via the 
communications medium. 

Figure 3 and column 5, lines 59-61 of Ramamurthy cited in the Official Action 
regarding step (c) of claim 1 recite various options for processing an incoming 
telephone call if the called party is busy on the IP network. For example, lines 59-61 
of column 5 in Ramamurthy state that the call may be forwarded to a messaging 
system (i.e., a voice messaging system). The only similarity between this passage 
and step (c) of claim 1 is the common term "messaging," which was most likely 
located in a keyword search by the Examiner. However, forwarding a call to a voice 
mail system as disclosed in Ramamurthy fails to even remotely suggest updating 
presence information in a presence database that indicates to other end users as to 
how to contact the target end user via a text messaging protocol. For example, 
instructions for forwarding a call to an Internet-based voice mail system are usable by 
the network for forwarding phone calls, whereas presence information is usable by 
end users for contacting the target end user via a text messaging protocol. 

Step (d) of claim 1 recites transmitting the presence registration message to 
the presence server over an IP network. Column 3, lines 41-43 of Ramamurthy cited 
in the Official Action regarding step (d) of claim 1 recites: 
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ITN 110 cooperatively operates with a telephone server 111 for the 
purposes of call setup, call control and call completion. In addition, a 
database 112 is connected to a telephone server 111, in which a list 
of currently active users on ITN 110 is maintained. 

There is no disclosure in the above-quoted passage or in Figure 1 of Ramamurthv of 

routing a presence registration message to a presence server. This passage, in 

combination with Figure 1, merely lists different call forwarding options usable by the 

network to forward calls when the called party telephone line is busy. Such 

information is not presence information as claimed in the independent claims of the 

present application. 

Thus, because Ramamurthv fails to teach or suggest the invention as claimed 
in the independent claims of the present application that relate to automatic presence 
registration (claims 1, 22, 29, and 42), the rejection of these claims and their 
respective dependent claims should be withdrawn. 

With regard to claims 11-15, 35 and 51-59, the Official Action states: 

Ramamurthv discloses a method for completing long distance POTS 
calls with IP telephony endpoints comprising: 

(a) receiving, at a presence registration and routing node, an IP 
message for determining presence information for a first end user, the 
presence information indicating a communication medium for 
contacting the first end user using a messaging protocol and the fact 
that the first end user is currently available to receive messaging 
protocol messages via the communications medium (Figures 2-5, 
column 5, lines 59-61 and column 5, lines 64-67). 



Column 5, lines 59-61 of Ramamurthv cited in the above-quoted passage from the 

Official Action states, "the called party is then given the option at step 210 to forward 
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the incoming call to a messaging system." Column 5, lines 64-67 of Ramamurthy 
cited in the above-quoted passage from the Official Action states: 



If the called party at step 210 does not elect to send the call to a 
messaging system, then at step 212 the call is terminated in a 
messaging system at which the called party can leave a message. 



The quoted passages of Ramamurthy relate to forwarding an incoming call to voice 
mail. These passages are not even remotely related to receiving a query for 
presence information for a target end user to which other end users are subscribed in 
a presence database. 

With regard to paragraph (b) of claim 11, the Official Action indicates that 
column 4, lines 23-45 of Ramamurthy disclose this element. Paragraph (b) of claim 
1 1 recites formulating a query to a presence database for obtaining the presence 
information. Column 3, lines 23-45 of Ramamurthy states as follows: 



Database 112 has stored their own information associated with each 
end user currently logged on to ITN 110. Specifically, when a user 
terminal logs on to ITN 110, he identifies himself with the user ID. In 
addition, the user is prompted for the telephone number from which 
the connection is being established, or that telephone number may be 
provided to the ITN via an automatic number identification (AN I) 
provisioning through LEC 106. Further, database has stored therein 
information indicating the subscribe to IP telephony feature set 
associated with the subscriber/user at the called telephone number, 
such as call forwarding on IP and call waiting on IP. When the end 
user at terminal 108 logs on to ITN, therefore, a record is created in 
database 112 which indicates the user's telephone line number, the 
user's ID and the IP telephony feature set associated with that user, 
and the fact that the identified telephone line is active on the IP 
network. The record indicates whether or not that telephone line is 
currently active on an IP telephony call. If the called telephone line is 

-26- 



Serial No. 09/627,253 

active on the IP network but not currently active on the IP telephony 
call, then the user is either keeping his terminal idle or is browsing on 
the Internet or an Intranet. 

The above-quoted passage of Ramamurthv states that database 112 stores 
information indicating whether the called end user is active on the Internet, is capable 
of receiving an IP telephony call and the IP telephony features to which the user 
subscribes. Nothing about this passage teaches or suggests formulating a query to a 
presence database because database 112 does not store presence information. 
Presence information is claimed in the independent claims of the present application 
as information usable by a presence server for automatically indicating to end users 
subscribed to a target end user in a presence database as to how to contact the 
target end user via a text messaging protocol. Such information is not conventionally 
kept by PSTN networks. In contrast, Ramamurthv indicates alternate ways for 
processing calls when a called party line is busy, which is a common feature in PSTN 
networks. 

Step (c) of claim 1 1 recites obtaining presence information from the presence 
database. The Official Action again indicates that column 4, lines 23-45 discloses 
obtaining presence information from the presence database. This is the same 
passage of Ramamurthv that the Official Action cites as relevant to step (b) of claim 
1 1 . As indicated above, this portion of Ramamurthv merely recites alternate methods 
for contacting an end user whose telephone line is busy. There is no teaching or 
suggestion of obtaining presence information. 
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The Official Action indicates that Figure 2 and column 6, lines 10-22 of 
Ramamurthv disclose step (d) of claim 1 1 . Step (d) of claim 1 1 recites forwarding the 
presence information to a second end user and wherein the second end user uses 
the presence information to determine the appropriate communication medium for 
contacting the target end user using a text messaging protocol and the availability of 
+1^0 {grg@+ user to receive text messaging protocol communications via the 
communications medium. Column 6, lines 10-22 of Ramamurthv recites: 



If, in step 204, the called telephone line is determined to be active on 
an IP telephony call but a determination was made at step 205 that a 
call waiting on IP telephony feature is not associated with the called 
party, then at step 213, a determination is made whether the called 
party subscribes to call forwarding on IP feature. If not, at step 214, 
telephone server 111 signals PSTN 104 to return a busy signal to the 
calling party. If a call forwarding feature on IP is associated with the 
called telephone line, then, at step 215, the incoming call can be 
directed to an adjunct 120 or 121 as previously described. 
Alternatively, the called party can direct the call to be forwarded to an 
alternate destination on either the ITN or PSTN, such a cellular 
telephone. 



The quoted portion of Ramamurthv merely indicates different options for processing 
an incoming telephone call in response to features to which the called party 
subscribes. In contrast, step (d) of claim 1 1 recites forwarding presence information 
to an end user that the end user can use to contact the target end user via a text 
messaging protocol. Ramamurthv does not teach forwarding any information back to 
the calling party. Rather, Ramamurthv teaches different call processing operations 
performed by the network. 



-28- 



Serial No. 09/627,253 

Thus, for all of the reasons stated above, Ramamurthv fails to teach or even 
remotely suggest the invention claimed in the independent claims of the present 
application that relate to processing presence queries (claims 11, 35, and 51) or their 
respective dependent claims. Thus, the rejection of these claims should be 
withdrawn. 

Claim Rejections 35 U.S.C. § 103 

Claims 2-4, 9, 10, 18-21, 23, 27, 28, 30-34, 36-41, 43-45, 47, 50 and 50 were 
rejected under 35 U.S.C. § 103(a) as unpatentable over Ramamurthv in view of U.S. 
Patent No. 5,999,525 to Krishnaswamv et al. (hereinafter, Krishnaswamv ). This 
rejection is respectfully traversed. 

As stated above, the present invention relates to methods and systems for 
automatically generating presence registration messages based on telephony actions 
and for responding to queries for presence information, where the presence 
information is usable by a presence server to automatically indicate to end users 
subscribed to the target end user in a presence database that the target end user is 
accessible via a text messaging protocol. For all of the reasons stated above, 
Ramamurthv fails to teach such methods and systems. 

Krishnaswamv likewise fails to teach anything remotely related to the claimed 
invention. Krishnaswamv is directed to a method for sending telephone calls and 
multimedia information across the Internet. There is no mention in Krishnaswamv of 
the presence protocol, automatically generating presence information in response to 
a PSTN action, or processing presence protocol queries. In direct contrast to the 
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present invention, Figure 57 of Krishnaswamv cited by the Official Action as relevant 
to the claims of the present application indicates that a user must manually update 
his or her own IP telephony profile via a login screen. This profile is usable by the 
network, rather than other end users, to complete IP telephony calls to the called 
party. Thus, for these additional reasons, it is respectfully submitted that a 
combination of Ramamurthy and Krishnaswamv teaches away from the claims the 
present application that relate to automatic presence registration in response to a 
PSTN action. 

On page 4 and 5 of the Official Action, the Examiner indicates that 

Krishnaswamv discloses certain SS7 messages, such as 1AM messages and TCAP 

messages. Figure 1F and column 93, line 21 of Krishnaswamv are indicated in the 

Official Action as disclosing an initial address message. Column 93 beginning at line 

17 of Krishnaswamv states as follows: 

The hybrid Internet telephony switch 221 grows out of the marriage of 
router architectures with the circuit switching architecture. A call 
arriving on the PSTN interface 257 is initiated using (ISUP) signaling, 
with an initial address message (IAM) containing a called party 
number and an optional calling party number. The PSTN interface 
transfers the IAM message to the host processor. The host processor 
examines the PSTN network interface of origin, the called party 
number and other IAM parameters, and selects an outgoing network 
interface for the call. The selection of the outgoing network interfaces 
made on the basis of routing tables. The switch 221 may also query 
external service control point (SCP) 276 on the Internet to request 
routing instructions. Routing instructions, whether derive locally on 
switch 221 or from the STP 276, may be defined in terms of a subnet 
to reach a particular destination. (See column 93, lines 17-33 of 
Krishnaswamv .) 
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The above quoted passage of Krishnaswamv cited by the Examiner indicates the 
traditional use of the 1AM message, i.e., for call setup. In contrast, dependent claim 2 
in combination with step (a) of claim 1 of the present specification recite updating 
presence information in a presence database in response to an IAM message 
relating to a call made by the target end user . Thus, the present invention takes an 
IAM message, which is conventionally used for call setup, and uses it for a 
completely different purpose of updating presence information. There is simply no 
such teaching in Ramamurthv or Krishnaswamv . Thus, for this additional reason, the 
rejection of the claims that relate to using conventional PSTN signaling to update 
presence information should be withdrawn. 

Claims 5 and 46 were rejected as unpatentable over Ramamurthv in view of 
U.S. Patent No. 5,373,930 to McConnell et al. (hereinafter, " McConnell "). This 
rejection is respectfully traversed. 

Claim 5 d e p e nds from claim 1 and c l a i m 46 depends from claim 42. As stated 
above, Ramamurthv fails to teach the invention claimed in independent c l a i ms 1 or 
claim 42. McConnell likewise lacks such teaching or suggestion. McConnell is 
directed to a call monitoring system that maintains subscriber account balance 
information, such as prepaid financial account balance or a usage amount that the 
subscriber is not allowed to exceed, in an SCP. The SCP provides instructions for 
routing calls through a special service node that plays announcements, performs call 
timing, collects digits, and disconnects the call as necessary, in accordance with the 
subscriber's account balance. (See column 4, lines 37-64 of McConnell .) Such 
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accounting information has nothing to do with the presence protocol. Nonetheless, 
on page 6, the Official Action indicates that McConnell's disclosure of an HLR 
renders claims 5 and 46 obvious in combination with Ramamurthv . The cited portion 
of McConnell is as follows: 



A home location register 134 is conventionally coupled by a signaling 
path 136 with STP network 116. HLR 134 serves standard functions 
in the wireless network, such as managing profiles and authentication 
information for subscribers in mobile stations. HLR 134 is typically 
located on an SCP operated by the home service provider of a record 
for a given subscriber. In addition, network 100 typically includes a 
visitor location register ("VLR"), which stores the service profile 
information for mobile stations currently being served by the carrier 
operating SCP 124. The VLR may be maintained on the MSC on the 
SCP, or at another suitable location. (See column 11, lines 52-63 of 
McConnell .) 



The cited portion of McConnell merely state the conventional uses of an HLR and a 

VLR, that is, storing subscriber profile information and information regarding the 

subscriber's current location. In contrast, the invention claimed in claims 4 and 49 

recite that activation of a mobile handset triggers a message to an HLR, which is also 

used for presence registration. Using a message that was traditionally used only for 

HLR registration for presence registration is simply not taught by McConnell . Thus, 

for this additional reason, the rejection of claims 4 and 49 should be withdrawn. 

Claim 5 has been rewritten in independent form to include automatically 

updating presence protocol information in a presence database based on a signaling 

system 7 message sent in response to a telephony-related action by a mobile 

subscriber. The signaling system 7 message is sent to update the status of the 
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target end user in an HLR or VLR. Thus, in independent claim 5, a signaling system 
7 message relating to mobile call signaling is used for a new purpose to update 
presence information in a presence database. 

There is no teaching or suggestion in Ramamurthv nor McConnell of this 
method. As stated above, Ramamurthv is directed to an Internet call forwarding 
system that provides information to the network rather than end users for contacting 
a party whose telephone line is busy due to Internet access. McConnell's only 
teaching of messages between HLRs and VLRs relate to standard functions 
performed by these nodes, i.e., storing subscriber information. There is no teaching 
or suggestion in either of these references, when taken individually, or when 
combined of updating presence protocol information based on an SS7 message used 
to update the status of a subscriber in an HLR or a VLR. Accordingly, it is 
respectfully submitted that the rejection of claim 5 should be withdrawn. 

New Claims 

New dependent claims 65-78 are added. Claims 65, 67, 69, 71, 73, 75, and 
77 relate combining SS7 signal transfer functionality with presence registration and 
processing functionality. These claims are supported, for example by Figure 3 of the 
present application and page 11, lines 12-14 of the present specification. 

New dependent claims 66, 68, 70, 72, 74, 76, and 78 recite that the text 
messaging protocol over which the target end users can be contacted is an instant 
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messaging protocol. Support for these claims is found, for example, on page 5, line 
19 - page 6, line 1 1 of the present specification. 



In light of the amendments and remarks above, it is respectfully submitted that 
the claims are now in condition for allowance. If any small matter should remain 
outstanding after the Patent Examiner has had an opportunity to review the above 
Remarks, the Patent Examiner is respectfully requested to telephone the 
undersigned patent attorney in order to resolve these matters and avoid the issuance 
of another Official Action . 

Although no fee is believed to be due, the Commissioner is hereby authorized 
to charge any fees associated with the filing of this correspondence to Deposit 
Account No. 50-0426. 



CONCLUSION 



Respectfully submitted, 



JENKINS, WILSON & TAYLOR, P.A. 





Customer No.: 25297 



1322/40/2 GAH/sed/gwc 
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